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APPARATUS ACCESSED AT A PHYSICAL I/O it was necessary to limit access to these input/output pro- 

ADDRESS FOR ADDRESS AND DATA cessors to trusted code, generally operating system code and 

TRANSLATION AND FOR CONTEXT device drivers, in order to preclude application programs 

SWITCHING OF I/O DEVICES IN RESPONSE undertaking operations which would interfere with 

TO COMMANDS FROM APPLICATION 5 other application programs or issuing commands which 

PROGRAMS would wreak havoc with the system. Apart from any other 

problems, writing directly to the input/output devices creates 

This is a continuation of application Ser. No. 08/441.081. » security problem in a multi-tasking system because the 

filed May 5. 1995. now abandoned. "^'^^ '° '^^"^ fr""" mput/output devices such as 

the frame buaer means an apphcation program may read 

BACKGROUND OF THE INVENTION what other programs have written to the device. For these 

1 iH f >i T * reasons, both the IBM and CDC architectures kept any but 

1. hield ot the Invention privileged operating system code from writing to operating 
This invention relates to computer systems, and more system memory and to the input/output devices. 

particularly, to hardware for controlling the translation of ^gy^^ ^^^^^^ Equipment Corporation (DEC) 

addresses and context for mput/output devices in a new pj^p^^ computer appeared In the original embodiment of 

input/output architecture for computer systems. architecture, all of the components of the computer are 

2. History of the Prior Art joined to a system backplane bus. The central processing 
In the 1960s, International Business Machines (IBM) and unit and any other component of the computer (except main 

Control Data Corporation (CDC) produced mainframe com- 20 memory) addresses each other component as though it were 

puters with architectures in which a central processing xmit an address in memory. The addresses for the various hard- 

(CPU) controlled program manipulation and separate input/ ware components including input/output devices simply 

output processors (called channel processors or peripheral occupy a special part of the memory address space. Only the 

processor units) controlled input/output operations. The address itself indicates that a component is a device such as 

input/output processors had instruction sets which allowed 25 an input/output device which is other than memory. When 

them to canry out the somewhat limited functions designated the central processing unit wants to accomplish an input/ 

by commands placed in memory by the central processing output operation, it simply writes or reads addresses 

unit. For example, the input/output processors knew how to assigned to the particular input/output device in memory 

access data on disk and place data on an output display. This address space. This architecture allows all of the operations 

form of architecture made, and in some cases still makes, a 30 available to the central processing unit to be utilized in 

great deal of sense. At that time, central processing units accomplishing input/output operations and is, therefore, 

were very expensive; and using the central processing unit quite powerful. Moreover, this allows the input/output 

to accomplish input/output operations was very wasteful. operations to be accomplished without the need for special 

Neither the CDC nor the IBM input/output processors were commands or for special resources such as input/output 

as powerful as the central processing unit and thus could be 35 processors. It also allows the use of very simple input/output 

produced relatively inexpensively. These architectures controllers which typically amount to no more than a few 

allowed individual computers to be built to emphasize registers. 

operations by the central processing unit or operations by the as with the earlier IBM and CDC architectures and for the 

input/output devices. By building a faster central processing same reasons, writing to the input/output devices directly by 

unit, the main processing functions could be made to go other than trusted code is prohibited by the POP 11 operating 

faster; while by building faster input/output processors, the systems. The PDPll architecmre provides a perfect arrange- 

input/output operations could be accelerated. ment for handling this. This architecture, like some of its 

As an example of this type of operation, in the IBM predecessors, incorporates a memory management unit 
system, the central processing unit would signal which designed to be used by an operating system to allow the 
input/output operation it desired by writing channel com- 45 addressing of virtual memory. Virtual memory addressing 
mands to main memory and signaling a channel processor provides access to much greater amounts of memory than 
that there was something for it to do. The channel processor are available in main memory by assigning virtual addresses 
would read those commands and proceed to execute them to data wherever it may be stored and translating those 
without aid from the central processing unit. If an input/ virtual addresses to physical addresses when the data is 
output processor was instructed to do something, it would do 50 actually accessed. Since operating systems use memory 
it. As long as the operation was safe, there was 00 problem. management units to intercept virtual addresses used by the 
Unfortunately, if the operation was something prohibited central processing unit in order to accomplish the virtual- 
like reformatting the hard disk which contained the basic to -physical address translation, operating systems may sim- 
operating system, the input/output processor would also do ply provide no virtual-to-physical translations of any input/ 
that. 55 output addresses in the memory management unit for 

These architectures were designed to allow programs to application programs. Without a mapping in the memory 

time share (multi-task) the central processing unit. With an management unit to the physical addresses of input/output 

operating system which allows muUi-tasking, it is necessary devices, the application program is required to use a trusted 

to protect the resources allotted to one apphcation program intermediary such as a device driver in order to operate on 

from operations conducted by other application programs so 60 an input/output device in the PDPll architecture, 

that, for example, one program cannot write to memory over Thus, in a typical computer system based on the PDPll 

the space utilized by another program. An important part of architecture, only trusted code running on the central pro- 

this protection is accomplished by keeping apphcation pro- cessing unit addresses input/output devices. Although this 

grams from writing directly to portions of the system where architecture allows all of the facilities of the central pro- 

they might cause harm such as main memory or the input/ 65 cessing unit to be used for input/output, it requires that the 

output devices. Since the input/output processors would do operating system running on the central processing unit 

whatever they were instructed in the IBM and CDC systems, attend to all of the input/output functions. Requiring a trap 
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into the system software in order to accomplish any input/ may read. Since write operations are buffered, all write 
output operation slows the operation of the computer. commands in the write buffer queues must be processed 
Moreover, in contrast to earlier systems, in this architecture, through the buffers before any read can proceed. And during 
there is no process by which the input/output performance of a read operation, the central processing system cannot 
the system can be increased except by increasing the speed 5 conduct other operations since it must typically remain on 
of the central processing unit or the input/output bus. This is the input/output bus in order to read synchronously the data 
an especial problem for programs which make heavy use of being transferred. In some systems, some read operations 
input output/devices. Video and game programs which take as much as twenty limes as long as write operations, 
manipulate graphics extensively and make extensive use of Since the operating system running on the central pro- 
sound suffer greatly from the lack of input/output speed. cessing unit must handle all of the reads and writes to 
This problem is especially severe because when only input/output devices in this architecture, the central process- 
trusted code can access input/output devices, then all ing unit is further slowed by this hardware bias when dealing 
accesses must be through this trusted code. That means that with input/output intensive applications. For example, 
each operation involving input/output devices must go manipulating graphic images typically requires extensive 
through a software process provided by the operating system 15 read/modify/write operations. Many application programs 
and the input/output device drivers. The manner in which which make extensive use of input/output devices, including 
this is implemented is that when an application program is a great number of games, are unable to function with 
running on the central processing unit, the addresses it is architectures which require that the operating system read 
allowed to access are mapped into the memory management and write to the output devices on behalf of the applications, 
unit by the operating system. None of these addresses may 20 ^^^^^ obtain the speed necessary to display their 
include input/output addresses. When an application pro- operations satisfactorily such programs must read and write 
gram desires to accomplish an input/output operation, it to the input/output devices directly. This has always been 
executes a subroutine call into the operating system library allowed by the Microsoft DOS operating system but by none 
code. This subroutine performs an explicit trap into the of the advanced operating systems such as Unix. Ultimately, 
operating system kernel. As a part of the trap, the operating 25 ^i^^ extensive urging by the windows system developers, 
system changes the memory management unit to create the operating system designers of workstation operating 
mappings to the device registers. The operating system systems have grudgingly allowed applications to read and 
kernel translates the virtual name used for the input/output write to the graphics circuitry directly by mapping some of 
device by the application program into the name of a device the physical addresses which the input/output devices 
driver. The operating system kernel does a permission check 30 decode to their memory address space. This allows windows 
to ensure that the application is permitted to perform this system developers to read and write to the graphics hard- 
operation. If the application is pennitted to perform the ware directly even though the security and integrity of the 
operation, the operating system kernel calls the device driver system is compromised by so doing. There have also been 
for the particular input/output resource. The input/output multitasking system which have aUowed application pro- 
device driver actually writes the command for the operation 35 grams to write directly to the graphics hardware. However, 
to the registers of the input/output hardware which are now these systems have required that the operation be accom- 
mapped by the memory management unit. The input/output plished using the operating system software to trap input/ 
device responds to the command by conducting the com- output accesses and accomplish context switching to assure 
mandcd operation and then generates signals which indicate that application programs do not interfere with one another; 
whether the operation has succeeded or failed. The input/ 40 consequently, the result is significantly slower than desir- 
output device generates an interrupt to the device driver to able. One such system is described in U.S. Pat. No. 5,127, 
announce completion of the operation. The device driver 098. 

reads the signals in the registers of the input/output device For all of these reasons, many games simply avoid 

and reports to the operating system the success or failure of multitasking operating systems such as windows systems. In 

the operation. Then the operating system returns from the 45 general, games must be operated in single tasking systems 

trap with the success or failure indication, restores the such as Microsoft DOS which allows an unlimited form of 

mappings for the application and thus removes the mappings writing directly to the input/output devices while sacrificing 

for the device registers, and ultimately returns from the the integrity of the system. 

subroutine call reporting the success or failure of the opera- It is very desirable to provide a new architecture which 

tion to the unprivileged code of the application. 50 allows input/output operations to proceed at a faster speed so 

This sequence of steps must take place on each operation that application programs which make significant use of the 

conducted using input/output resources. The process is inor- input/output components may function in the advanced 

dinately long, and a recitation of the steps involved illus- multi-tasking operating systems without sacrificing system 

trates why applications using graphics or other input/output integrity. 

devices extensively cannot be run at any real speed on such 55 Another major problem has surfaced with computers 

systems. running multi-tasking operating systems. In a computer 

This problem has been made worse by the tendency of system, different application programs must have access to 

hardware manufacturers to bias their systems in favor of the different input/output devices of the system. In order for 

write operations to the detriment of read operations. This an application program to run with an input/output device, 

bias has gradually increased as processors have become 60 various registers of the input/output device should hold 

faster (the only way to accelerate a system having the PDPll values which control the operation of the device. For 

architecture) while bus speed has tended to lag requiring that example, certain registers of a graphics control circuit are 

write operations on the bus be buffered. The interface in this typically filled with values which indicate in some manner 

type of architecture (including Intel X86 type systems) the values which are to be used by the graphics control 

between input/output devices and the input/output bus 65 device in its color lookup tables. Similarly, other registers 

includes a plurality of registers to which the central pro- hold other values needed for the operation of a graphics 

cessing unit may write and which the central processing unit controller and other input/output devices with each applica- 
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tion program. Typically, these values and other values which 
must be changed for operation of a particular input/output 
device with a particular application program are referred to 
as the "context" of that application for that input/output 
device. 

Different application programs provide different context 
values for the registers of input/output devices and thus 
require different context on the input/output device in order 
to function most effectively. In certain cases, the same 
application program will place different context on an input/ 
output device in order to accomplish different specific 
operations with the device. In computer systems and espe- 
cially in multi-tasking systems where different application 
programs run on the same processor in interleaved 
operations, it is necessary in order for each application 
program to make most effective use of the input/output 
devices to switch the context of various input/output devices 
whenever a new application has access to the input/output 
device. Often it is also desirable to switch the context on an 
input/output device when, though the same application 
program is accessing the input/output device, the use of the 
device has changed. 

ftior art multi-tasking systems have devised various ways 
of handling this problem. One advanced technique described 
in U.S. Pat. No. 5,127,098 requires that a system memory 
management unit provide a valid mapping for a single 
application program at a time to a single address space of the 
input/output device. Whenever a different application is to 
use the input/output device, the system traps the attempt, 
intermpts the operation, saves the present context, provides 
a new mapping to the memory management unit for the new 
application program, provides new context to the input/ 
output device for the application program, and restarts the 
system so that the new application may access the device. 

A problem with this method is that the operating system 
must be called to change the context for each different 
application. This is quite slow and drastically delays the 
operation of a multi-tasking system which is constantly 
switching between application programs. 

It is desirable to provide apparatus and a method for 
rapidly switching context in a computer system. 

It is also desirable to provide hardware which is capable 
of accomplishing both address translations and context 
changes for optimal operation of input/output devices in 
multi-tasking systems. 

SUMMARY OF THE INVENTION 

It is, therefore, an object of the present invention to 
provide apparatus and a method for rapidly translating 
input/output addresses and placing context on the input/ 
output devices. 

It is another object of the present invention to provide a 
hardware arrangement which is capable of both providing 
address translations and changing context for input/output 
devices. 

These and other objects and features of the present 
invention are accomplished in a hardware input/output 
address translation apparatus for translating addresses fur- 
nished by an application program to physical input/output 
device addresses and furnishing context for an input/output 
device to function with an application program. The appa- 
ratus is designed to test whenever a translation requires a 
change in context and assure that the correct context is on 
the input/output device before the translation is utilized. 

These and other objects and features of the invention will 
be better understood by reference to the detailed description 
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which follows taken together with the drawings in which 
like elements are referred to by like designations throughout 
the several views. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a prior art computer system. 

FIG. 2 is a block diagram of a computer system utilizing 
the architecture of the present invention. 
10 FIG. 3 in a diagram illxistrating the operation of software 
in the architecture of the present invention. 

FIG. 4 is a block diagram of a portion of a personal 
computer system such as that illustrated in FIG. 2 designed 
in accordance with the present invention. 
15 FIG. 5 illustrates the address and data bits utilized in one 
embodiment of the invention. 

FIG. 6 is an illustration of entries in a translation table 
used in accordance with the invention. 

FIG. 7 is a block diagram illustrating details of the circuit 
of FIG. 4. 

NOTATION AND NOMENCLATURE 

Some portions of the detailed descriptions which follow 

25 are presented in terms of symbolic representations of opera- 
tions on data bits within a computer memory. These descrip- 
tions and representations are the means used by those skilled 
in the data processing arts to most effectively convey the 
substance of their work to others skilled in the art. The 

30 operations are those requiring physical manipulations of 
physical quantities. Usually, though not necessarily, these 
quantities take the form of electrical or magnetic signals 
capable of being stored, transferred, combined, compared, 
and otherwise manipulated. It has proven convenient at 

35 times, principally for reasons of common usage, to refer to 
these signals as bits, values, elements, symbols, characters, 
terms, numbers, or the like. It should be borne in mind, 
however, that all of these and similar terms are to be 
associated with the appropriate physical quantities and are 

40 merely convenient labels applied to these quantities. 

Further, the manipulations performed are often referred to 
in terms, such as adding or comparing, which are commonly 
associated with mental operations performed by a human 
operator. No such capability of a human operator is neces- 

45 sary or desirable in most cases in any of the operations 
described herein which form part of the present invention; 
the operations are machine operations. Useful machines for 
performing the operations of the present invention include 
general purpose digital computers or other similar devices. 

50 In all cases the distinction between the method operations in 
operating a computer and the method of computation itself 
should be borne in mind. The present invention relates to a 
method and apparatus for operating a computer in process- 
ing elearical or other (e.g. mechanical, chemical) physical 

55 signals to generate other desired physical signals. 

DETAILED DESCRIPTION 

Referring now to FIG, 1, there is illustrated a computer 
system 10 constructed in accordance with the prior art based 
60 on the architecture of a DEC PDPll computer. The system 
10 includes a central processing unit 11 which executes the 
various instructions provided to control the operations of the 
system 10. The central processing unit 11 is joined to a bus 
12 adapted to carry information between the various com- 
es ponents of the system 10. The bus 12 is separated in the 
figure into address bus 12a and data bus 12rf, but both will 
be referred to as the bus 12 unless the context requires 
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Otherwise. Joined to the bus 12 is main memory 13 which is virtual memory which is not presently available in main 

typically constructed of dynamic random access memory memory, the operating system moves data around between 

arranged in a manner well known to those skilled in the prior long term memory and main memory 13 to make the data 

art to store information during a period in which power is available and then allows the operation to proceed. If the 

provided to the system 10. In more advanced systems based 5 operation involves a change in context at an input/output 

on this architecture, the main memory 13 may be positioned device (e.g., the values held in registers and the like which 

on a bus more closely associated with the central processing allow the input/output device to carry out the functions 

unit 11 so that operations between the central processing unit commanded by the application), the context is changed by 

11 and main memory need not occupy the bus 12 and may the operating system; and, then, the operation is allowed to 

be carried on more rapidly. In any case, the bus 12 may be proceed. When the driver writes to the virtual address of the 

treated as essentially an input/output bus. input/output device, the memory management unit 20 uses 

Connected to the bus 12 are various peripheral compo- the operating system translations of virtual to physical 

nents such as long term memory 16, a frame buffer 17 to addresses now available to transfer the command to the 

which data may be written which is to be transferred to a input/output device addressed. The device driver actually 

device such as a monitor 18 for display, a sound board 19, ^5 writes the data of the command for the operation to the 

and a local area network (LAN) 15. Each of these peripheral registers of the input/output hardware. The input/output 

components is an input/output device to which data must be device responds to the command by conducting the com- 

written and from which data must be read only by the central manded operation and then generates signals which indicate 

processing unit using trusted code associated with the oper- whether the operation has succeeded or failed. The input/ 

ating system. Typically, each of these peripheral components 20 output device generates an interrupt to the device driver to 

includes a set of registers to which this trusted operating announce completion of the operation. The device driver 

system code may write and from which the trusted code may reads the signaJs in the registers of the input/output device 

read in order to accomplish these operations. and reports to the operating system the success or failure of 

Associated with the central processing unit 11 and the the operation. Then the operating system returns from the 

address bus 12fl is a hardware memory management unit 20. 25 ^^P "^^^ success or failure indication and ultimately 

The memory management unit 20 typically includes cir- returns from the subroutine call reporting the success or 

cuiU7 for accomplishing a translation of virtual addresses to failure of the operation to the unprivileged code of the 

physical addresses. This allows an application program application. 

running on the central processing unit 11 to address memory To speed access of memory, a memory management unit 

or an input/output device using a virtual address. The virtual 30 often incorporates an address cache such as the lookaside 

address is translated by the memory management unit 20 buffer referred to above which provides caching of virtual 

into a physical address using page tables in main memory and physical memory address translations. The address 

through which a lookup is accomplished. The physical cache typically provides fast translation of memory 

address is then placed on the address bus 12a where it may addresses in over ninety percent of memory operations. A 

be detected by one of a number of controllers each associ- 35 miss in the address cache initiates the page table lookup 

ated with one of the input/output devices on the bus 12. The operation in main memory, and the virtual and physical 

device to which the command is addressed may then address translations obtained are stored in the address cache, 

respond to the command placed on the data bus 12d. Since the memory management unit does main memory 

The memory management unit 20 usually includes an page table lookups, the central processing unit may proceed 

address cache such as a lookaside buffer in which recently 40 with other operations while the address translation is being 

used virtual addresses and their associated physical obtained; and the slowness of the process described above is 

addresses are stored. The address cache provides very rapid alleviated to some extent for memory accesses. This helps to 

translation for recently accessed addresses and eliminates speed main memory accesses appreciably, 

the time consuming page table lookups in main memory for However, even though input/output addresses are treated 

a great proportion of memory address translations. 45 as memory addresses residing in locations to which access 

In the system of FIG. 1, an application program requiring is limited, the semantics of read and write operations by the 

access to a device on the input/output bus sends a subroutine central processing unit as applied to memory and to device 

call to the operating system library code requesting the registers differ in ways that prevent input/output accesses 

operating system to do the operation on its behaff. This from being cached. Since input/output accesses are not 

subroutine is designed to provide an explicit trap into the 50 cached, they are slow. 

operating system kernel so that the operating system may A major reason for the lack of speed may be perceived by 

test to make sure that the operation is allowed. In some recognizing that each input/output operation can only be 

systems, when the operation is trapped to the operating carried out by trusted software processes of the operating 

system, the operating system places the address translations system which checks each operation before it is initiated to 

available to the operating system in the memory manage- 55 determine whether it may be safely carried out. Thus, every 

ment unit 20 so that device drivers will be able to access access of an input/output device must be trapped into the 

these addresses. In other systems, these address translations operating system, tested for permission to proceed, the 

are available to the operating system in software. The access accomplished using the operating system software 

operating system kernel conducts a permission check to and a device driver, the operation tested for completion, and 

ensure that the application is permitted to perform the 60 the results run back through the device driver and operating 

operation and then translates the virtual name for the input/ system software before being handed to the application 

output device furnished by the application into the name of program which initiated the operation. Most operations are 

a device driver. If the application is permitted to perform the entirely safe and could be carried out without this check, 

operation, the operating system kernel calls the device driver Since no operation which is unsafe can be run successfully 

for the particular input/output resource; and the driver 65 on such a system, most unsafe operations will have been 

accesses the appropriate physical addresses to accomplish eliminated in any software expected to be commercially 

the operation commanded. If the operation involves data in successful. More importantly, the need for software to take 
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over the operation from the hardware drasticaUy slows 
operations involving input/output devices. 

Not only do input/output operations have to be carried out 
by operating system software, the design of computers 
utilizing the PDPll architecture usually requires that regis- 
ters at each of the input/output devices be read by the central 
processing unit in order to accomplish any input/output 
operation. As central processing units have become faster in 
order to speed up PDPll type systems, it has been necessary 
to buffer write operations on the input/output bus 12 because 
the bus cannot keep up with the speed of the central 
processing unit. Thus, each write operation is transferred by 
the central processing unit to a buffer where it is queued until 
it can be handled; other buffers in the line between the 
central processing unit and an input/output device function 
similarly. Before a read operation may occur, all of these 
write buffers must be flushed by performing their queued 
operations in serial order so that the conect sequence of 
operations is maintained. Thus, a central processing unit 
wishing to read data in a register at an input/output device 
must wait until all of the write buffers have been flushed 
before it can gain access to the bus 12 to complete the read 
operation. Typical systems average eight write operations in 
their queues when a read operation occurs, and all of these 
write operations must be processed before the read operation 
may be processed. This has made read operations much 
slower than write operations. Since many of the operations 
required of the central processing unit with respect to 
graphics require reading very large numbers of pixels in the 
frame buffer, then translating those pixels, and finally rewrit- 
ing them to new positions, graphics operations have become 
inordinately slow. In fact, modern graphics operations were 
the first operations to disclose this Achilles heel of the 
PDPll architecture. 

Another problem with the PDPll architecture is that the 
only way to increase system speed is to increase the speed 
of the central processing unit. There is no system -wide way 
to accelerate input/output operations as was possible with 
the IBM and CDC mainframe computers; you can only 
make the central processing unit go faster. Although a disk 
controller maker can increase the speed of the disk, from a 
system standpoint, only the speed of the central processing 
unit can be increased. There is nothing that the central 
processing unit does that is special for input/output opera- 
tions so input/output speed is increased only as central 
processing unit speed is increased. The system cannot be 
balanced to suit special purposes. 
Overview of the new architecture 

The present architecture has been devised to overcome all 
of these problems of the prior art. This new input/output 
architecture cooperates with other components of existing 
systems based on the PDPll input/output architecture, runs 
legacy code for those systems, yet is able to drastically 
increase the speed of input/output operations for new appli- 
cation programs. In order to accomplish this, the new 
architecture allows read and write operations by apphcation 
programs to be made directly to the input/output devices. 
This eliminates the cumbersome multi-step software pro- 
cesses invoked by prior art systems using the operating 
system and trusted code for every input/output access. In 
order to accomplish the process safely, the new input/output 
architecture of the present invention utihzes an input/output 
control unit which first provides its own virtual name-to- 
physical-device address translation for all of the input/output 
• devices associated with the new input/output control unit on 
its own internal device bus. As a part of this translation, the 
input/output control unit assures that the correct context is 
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present for an input/output device to function with an 
application program before a first access is allowed. By 
enforcing this translation, application programs can write 
directly to input/output devices on the device bus associated 

5 with the input/output control unit without affecting assets of 
other application programs. Once this translation from vir- 
tual names furnished by the application programs (input/ 
output device indicators) to physical input/output devices on 
the device bus is accomplished and context for the applica- 

10 tion has been fiu-nished to the actual input/output device, 
translation of addresses of input/output devices on the 
input/output bus into physical addresses of those input/ 
output devices on the device bus is carried out directly by 
hardware at the input/output control unit. This hardware also 

15 checks permissions; and, when an operation is known to be 
safe, it is performed by hardware. When a translation 
operation fails, the operating system software is invoked. 
Tlius, rather than trapping every input/output operation to 
determine whether it is safe as is done in prior art computer 

20 systems based on the PDPll architecture, the present inven- 
tion traps and sends to operating system software only 
unsafe operations and allows hardware to accomplish most 
translations thereby greatly speeding the access of input/ 
output devices. 

25 The new input/output architecture has been designed so 
that it eliminates almost all operations which read registers 
of input/output devices. In order to accomplish this, the 
input/output control unit includes a firsl-in first-out (FIFO) 
unit for storing instructions directed to the input/output 

30 control unit. The FIFO unit queues incoming write opera- 
tions; but, unlike FIFO units used in prior art systems, it 
stores both addresses and data. This allows the write opera- 
tions to the input/output control unit to occur asynchro- 
nously so that both the central processing unit and the 

35 input/output control unit may be functioning independently 
of one another and neither need wait for operations of the 
other. 

To help maintain this asynchronous operating arrange- 
ment and to eliminate read operations to the greatest extent 

40 possible, the input/output control unit also includes an 
advanced direct memory access (DMA) device to assist data 
transfers involving input/output devices associated with the 
input/output control unit. The DMA device allows the results 
of input/output operations to be written by input/output 

45 devices to main memory rather than requiring read opera- 
tions by the central processing unit to obtain these results as 
in prior art systems. This eliminates ahnost all need for the 
central processing unit to read input/output devices and 
drastically increases the overall speed of input/output opera- 

50 tions. The DMA device includes its own memory manage- 
ment unit which allows writes from input/output devices to 
the virtual memory space of an application program without 
involving the operating system in the address translation 
after setup of the translation values. 

55 In order to achieve all of these improvements, the present 
invention utilizes an architecture illustrated in block diagram 
in FIG. 2. As may be seen, although the input/output 
architecture may be used with systems utilizing a single 
input/output bus for all operations, the architecture functions 

60 as well in a system 22 utilizing a local bus 27 such as the 
Peripheral Component Interconnect (PCI) bus or the Video 
Electronics Staiidards Association (VESA) local bus which 
may be associated with other input/output buses. While the 
discussion of this particular figure will assume that the bus 

65 27 is a PCI bus, the local bus 27 is also referred to in this 
specification as the input/output bus 27. In arrangements 
utilizing local buses, the central processing unit 21 and main 
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memory 23 are typically arranged on a processor bus 24 and 
a memory bus 26, respectively, and are joined to a bridge 
unit 25. The central processing unit 21 typically includes a 
memory management unit such as that described above. The 
bridge unit 25 provides write buffering for operations 
between the central processing unit 21 and the input/output 
bus 27, between the central processing unit 21 and main 
memory 23 on the processor bus 24 and the memory bus 26, 
and between the input/output bus 27 and main memory 23. 

Typically, various input/output devices are arranged on 
the input/output bus 27 as bus masters and bus slaves. In 
prior art systems, these local bus masters and slaves are 
those components (such as a graphics output device for 
connecting an output display monitor, a local area network, 
or a hard disk controller unit) which require the most rapid 
input/output operations for system success. If such local bus 
masters and slaves are connected to the input/output bus 27, 
they are utilized with the present architecture for the purpose 
of running legacy programs and input/output functions not 
implemented by the input/output control unit 29. 

In the new architecture, a single input/output control unit 
29 is shown joined to the input/output bus 27. The control 
unit 29 includes a hardware FIFO unit 31 for receiving 
incoming commands addressed to the input/output devices 
on a device bus 34. In this embodiment of the invention, 
only a single FIFO unit 31 is used although a plurality of 
FIFO buffers might be used at greater expense in order to 
further accelerate operations. The unit 29 receives physical 
addresses on the input/output bus 27 furnished by the system 
memory management unit and virtual names fiimished by 
application programs for operations to be performed at the 
FIFO unit 31 and controls the translation of those addresses 
and virtual names into physical addresses and context for all 
the associated input/output devices. The hardware unit 29 
includes the device bus 34 to which the individual input/ 
output devices such as a disk controller 32, a graphics output 
controller 33, and a sound generator 37 are shown joined. 
The unit 29 also includes a DMA unit 35 which is adapted 
to transfer data between the individual input/output devices 
and main memory for use by the central processing unit or 
other components of the system. 
The general operation of the input/output unit 29 

no. 3 illustrates the manner in which operations are 
conducted by software in the new architecture. An applica- 
tion program which utilizes the new architeaure may issue 
a command requesting permission from the operating sys- 
tem to map certain of the physical addresses decoded by the 
input/output control unit 29 into the address space of the 
application program. The operating system, using a new I/O 
driver #1, allots some portion of the system physical 
addresses which the input/output control unit 29 is decoding 
to the particular application program address space for its 
use only and installs the virtual-to-physical input/output bus 
address translations for the application program in the 
memory management unit. In a typical computer system, the 
memory management unit stores translations for what are 
referred to as pages of memory. If the size of the portion of 
system physical addresses allotted to an application program 
is a multiple of the memory management unit page size, then 
the I/O driver #1 can use the memory management unit to 
ensure that no more than one application program may 
access each area. 

Installing the appropriate translations in the memory 
management unit of the central processing unit 21 creates a 
path around the operating system by which the application 
program may read and write directly to the hardware of the 
input/output control unit 29. The application program then 
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writes to these allotted input/output bus addresses providing 
as data a virtual name of its choice for an input/output device 
on the device bus 34. The input/output control unit 29 takes 
the input/output address and the virtual name and uses it to 

5 first create and then install a translation between input/ 
output bus addresses and device bus addresses in its internal 
hardware and to place the context required by the applica- 
tion program in that input/output device. Once this has 
occurred and for so long as the application program contin- 

10 ues to run, the application program writes commands which 
the memory management unit associated with the central 
processing unit translates to the physical addresses on the 
input/output bus 27 for the input/output control unit 29; and 
the input/output control unit 29 further translates the input/ 

15 output bus addresses of the commands to physical addresses 
of input/output devices on the device bus 34. In this way, the 
application may write directly to the input/output unit in 
order to utilize an input/output device such as the graphics 
output controller 33 without requiring any software inter- 

20 vention by the operating system. 

As will be understood from the more detailed desaiption 
which follows, the use of many identically-sized input/ 
output device address spaces each assigned for use only by 
one application program allows the input/output addresses to 

25 be utilized to determine which application program has 
initiated any particular input/output write operation. 
Creation of a safe translation for an input/output device 

When the code of an application program is written to 
take advantage of the new architecture, a safe translation for 

30 an input/output operation utilizing a physical input/output 
device must first be created. A safe translation for an 
application to utilize an input/output device requires not 
only a correct physical address for the device but also conect 
context so that the device will function appropriately with 

35 the device. Since an application program may utilize the 
same input/output device for different purposes each requir- 
ing different context, the physical address and the correct 
context are sometimes referred to in this application as a 
"logical input/output device." To create such a safe 

40 translation, the application program sends a first special 
calling command adapted to call an input/output device to 
the input/output control unit 29; this special calling com- 
mand includes as data a predefined name such as "LINE — 
DRAWER" selected in accordance with a prescribed naming 

45 convention. The command is transferred directly to the FIFO 
unit 31 where it is placed in the FIFO queue. At this point, 
the central processing unit 21 may go off to other work. 
When this special calling command reaches the bottom of 
the FIFO unit 31, no translation between this virtual name 

50 (e.g., UNE_DRAWER) and a physical address on the 
device bus 34 is resident in hardware. The lack of a 
translation indicates an unsafe operation and causes an 
interrupt; and the predefined name is sent to a second new 
input/output driver associated with the control unit 29 called 

55 the "resource manager." The resource manager keeps an 
internal data base of data structures representing input/ 
output devices with physical addresses and contexts under 
the predefined names. The resource manager looks up this 
known predefined name in its internal database of data 

60 structures with predefined names and finds the data structure 
defining that device in the data base. The resource manager 
makes this predefined data structure available for immediate 
use. 

In one embodiment, the data structures are created as 
65 objects in an object oriented language. At times hereafter, 
the data structures will be referred to in this specification as 
objects. Moreover, commands provided to manipulate such 
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objects are typically referred to as methods; and so, in this 
specification, commands used to manipulate the data struc- 
tures are sometimes referred to as methods. 

In order to utilize the general device definition provided 
by the predefined data struaure, the application program 
then sends a "create" command and provides as data its own 
virtual name for that device and context. The resource 
manager creates an instance of the predefined data structure 
in its internal database naming that specific instance with the 
virtual name the application furnishes (e.g., MY_LINE_ 
DRAWER). Thus, in contrast to all prior art hardware which 
provide for address translations, the present hardware allows 
the user controlling the application program to select by 
explicitly providing a large (e.g., thirty-two bits) arbitrary 
name to be used in choosing the translation which is to be 
used by a hardware address translating unit. 

This new data structure includes the various properties of 
the general device from the data structure with the pre- 
defined name including the physical address on the device 
bus 34 of the input/output hardware which provides the 
function for the predefined name and a general set of context 
required by the hardware for operation. At this point, the 
application program may provide commands to modify the 
context stored by the new data structure to optimize the 
operation of the input/output device with the application 
program. 

Using a data structure 

When the application program later wants to utilize the 
newly-named data structure representing an input/output 
device, the application program writes the virtual name 
chosen with the special calling command which calls a data 
structure for the input/output device. The resource manager 
looks up the new data structure which has been created and 
(for a physical device) finds the context and physical address 
on the device bus 34 for the particular input/output device 
now described by the name. The resource manager changes 
any context required by the new input/output device which 
has been named to run the application program. The physical 
address on the device bus 34 which has been found is then 
placed in hardware to provide a translation from the input/ 40 
output bus addresses. When subsequent commands are sent 
to the same input/output device from the application 
program, they find the hardware translation and are routed 
directly to the particular addressed input/output device on 
the device bus 34. 
Unsafe operations 

In any case in which the input/output device to which the 
operation is directed is unknown to the hardware of the 
control unit 29 (an unsafe operation), the unit 29 calls the 
"resource manager" which runs on the central processing 
unit and functions as a portion of the operating system. The 
resource manager determines how the operation is to be 
handled. The operation may be a write by a new application 
program (such as that described above) requiring various set 
up operations before it may proceed. If an operation requires 
various context changes at the input/output device, this is 
handled by the resource manager before an address trans- 
lation for the device is placed in hardware. If an operation 
requires a procedure which is not yet in order under the 
operating system such as requiring data from memory which 
is not in memory at that time, the resource manager transfers 
the command to the operating system to perform the nec- 
essary memory transfers (or the like) which allow the 
commanded operation to proceed. Alternatively, the opera- 
tion may be directed to a device which is not otherwise 
associated with the control unit 29 such as a LAN interface 
or other bus master or slave on the input/output bus 27 which 



is not manufactured to cooperate with the imit 29. If such a 
device is addressed, the command is directed to the operat- 
ing system by the resource manager and handled by the 
operating system in the normal manner for input/output 
devices of the prior art. 

Thus, when an operation is unsafe as signified by not 
having a translation available to it in hardware, the com- 
mand is sent to the resource manager to assure that only safe 
operations can be performed. 
Address translations in hardware 

When the operation involves a device directly associated 
with the control unit 29 on its device bus 34, the commands 
after the first commands which are handled by the resource 
manager (creating the new data structure, attaching its new 
virtual name, providing any necessary device context, and 
creating the address translation) are sent by hardware 
directly to that device for execution. If the command 
requires that data be transferred to or from the application, 
the input/output device performs the transfer using the DMA 
unit 35. Upon the return of data to an application program 
in response to a command, the DMA unit 35 of the control 
unit 29 responds by transferring the data to main memory 
and notifying the central processing unit in a separate DMA 
operation of the existence of the data so that no input/output 
bus read operation by the central processing unit 21 is 
necessary to ascertain the result of the operation or to receive 
the data provided. 
Legacy applications 

In contrast to the operations discussed above, if an appli- 
cation program does not utilize the advantages of the present 
invention, it may still function in the manner of existing 
applications running on prior art systems. For example, 
older application programs operating in a multitasking sys- 
tem which have no knowledge of the present invention and 
are attempting a subroutine call to request the operating 
system to perform an operation using an input/output device 
associated with the unit 29 will trap into the operating 
system where its permission to proceed will be checked. The 
operating system will translate the call to the appropriate 
physical address and, finally, call the trusted code of the new 
system I/O driver #1 to execute the command. The new 
system I/O driver #1 functions in the manner of a typical 
driver of the prior art and executes the command by writing 
from its library of operations to the input/output control unit 
45 29 in the manner described above for application programs 
with knowledge of the input/output control unit 29. In fact, 
the new 1/0 driver #1 functions in a manner essentially 
identical to an application program with knowledge of the 
control unit 29 by providing a virtual name for the device 
specified to which the physical addresses for that device may 
be attached with a command calling the device. The new 
driver #1 has mapped to its address space a portion of the 
physical addresses decoded by the unit 29. The command 
data generated in response to the command from the older 
program is then transferred by this driver to the FIFO unit 31 
and processed in the same manner as are direct operations 
from an application with knowledge of the unit 29. Although 
this new I/O driver #1 functions as do other prior art drivers 
requiring the use of the operating system and stepping 
through the various stages of translation and permission 
checks, legacy software may utilize the architecture of the 
present invention without any additional requirements being 
placed on the system other than those which exist in the prior 
art. Moreover, this legacy code will run faster than on prior 
art systems because of the asynchronous result provided by 
the FIFO unit 31 and the write only operation that unit 
supports. 
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Specific details of the new architecture, the FIFO unit 

RG. 4 is a block diagram illustrating details of an 
embodiment of the input/output control unit 29 including the 
device bus 34 and the input/output devices arranged on that 
bus. As described above, the input/output control unit 29 
includes a decode unit 30 which receives commands directly 
from the input/output bus 27 and transfers the commands to 
a pusher circuit 53 which transfers the command to the FIFO 
unit 31. The FIFO unit 31 stores the data and the addresses 
for each of the commands being transferred to the input/ 
output devices associated with the input/output control unit 
29. The FIFO unit replaces the individual data registers used 
by input/output devices of the prior art for receiving data. 
However, in contrast to the registers used by the prior art for 
communication on the input/output bus 27, the FIFO unit 31 
allows many more commands to be processed much more 
rapidly and facilitates the asynchronous operations of the 
input/output devices and the central processing unit. In one 
embodiment, the FIFO unit 31 has thirty-two stages. This 
allows it to hold thirty-two individual serially ordered com- 
mands at any time. Although in one embodiment each of the 
stages of the FIFO unit 31 holds (along with the address bits) 
the data held by an individual register of a typical prior art 
input/output device, the system has the ability to store 
commands for over sixteen thousand 32 bit registers for each 
of 128 different application programs which may map 
different addresses decoded by the input/output control unit 
29. 

The address and data space for each command are pic- 
tured in FIG. 5. In one embodiment, twenty-three bits of 
address space, and thirty-two bits of data space are provided. 
The twenty-three bits of address space are sufBcient to map 
eight megabytes of address space on the input/output control 
unit 29. The eight megabytes of address space is divided into 
the 128 individual areas each having 64 Kbytes which may 
be allotted by the operating system to an application pro- 
gram. The upper seven bits of the address space are utilized 
to represent the 128 distinct areas which are available. 

There are a number of different embodiments of the FIFO 
unit 31 which may be used in the present invention. These 
include two general types of units. One type of FIFO unit 
(not shown) includes an individual FIFO buffer for each of 
the 128 individual areas (a total of 128 FIFO buffers in an 
embodiment having this many address areas). Another type 
of FIFO unit 31 includes typically one FIFO buffer for each 
general purpose processor used in the system. In the second 
embodiment of the FIFO unit, the use of each FIFO buffer 
is shifted among the various address areas assigned to 
different application programs so that it functions as a FIFO 
cache. This specification discusses in detail the second FIFO 
cache embodiment using a single processor and a single 
FIFO buffer because it is the more complex of the two 
embodiments. Those skilled in the art will easily understand 
the first type of unit which utilizes a plurality of FIFO 
buffers from the discussion of the more complex unit. 
Addresses 

In one embodiment of the more complex FIFO unit, the 
entries in the FIFO unit 31 include thirty-two bits of data 
space and twenty-three bits of address space. In another 
embodiment of the more complex FIFO unit which is 
discussed in detail hereafter, only fourteen bits of address 
space are provided in the FIFO unit 31 while the upper seven 
bits are held in a register to reduce overall FIFO size and the 
lowest two bits are dropped because the data bits are word 
aligned. The upper seven bits of the address represent the 
128 distinct areas of address space which are available and 
thus define the particular application program utilizing the 
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FIFO buffer 31. When a first command from an application 
program is transferred to the input/output control unit 29 
having an empty FIFO unit 31, the seven bits representing 
the area designated for that program are placed in a register 
42 (in the embodiment utilizing a register) where they are 
held until the application using the FIFO unit 31 changes. 
Since each area is assigned to only a single application 
program, the FIFO unit 31 is in effect a cache for the 
addresses and data of the particular one of the application 
programs presently having access to the input/output control 
unit 29. 

The addresses of each of these 128 areas are subdivided 
into eight separate sub-areas each having eight Kbytes of 
address space. The next lower three bits of the address space 
represent these eight sub-areas. The application program 
treats each of the eight sub-areas identically, designating at 
various times the physical addresses and the context of 
various input/output devices or data structures which rep- 
resent particular input/output devices and their context, to be 
accessed through each sub-area. As will be seen later, each 
of these sub-area addresses represents one of eight registers 
which may store the physical address of an input/output 
device on the bus 34 and thereby provide an address 
translation or may store a special value to indicate a software 
process (e.g., calling a data structure representing an input/ 
output device) is to be run. The two lowest bits of the 
address space represent byte positions in a command; in the 
preferred embodiment, the data is word aligned, and these 
bits are not included in the FIFO buffer 31. 

Consequently, eleven bits are left to represent a particular 
operation using the particular input/output device designated 
by the address translation in the sub-area. With eleven bits 
of address space, 2048 individual operations (or portions 
thereof) are available for each sub-area. As mentioned, in 
one embodiment the data structures are created as objects 
which represent the devices and their contexts which may be 
addressed in the sub-areas. The commands to the devices are 
then encoded as methods on each of these objects. This 
encoding of a sub-area as an object of a particular class is 
dynamic, and a new object representing a new device and its 
context may be encoded in the sub-area by an application 
program writing the special calling command which calls a 
device to the sub-area holding the address translation of any 
object. 

As pointed out above, when a program which is able to 
utilize the present invention first requests that the operating 
system map a portion of the addresses decoded by the 
input/output control unit 29 to its address space, the oper- 
ating system assigns physical addresses designating one of 
the 128 sixty-four Kbyte address areas of the input/output 
control unit 29 address space to the application. Thereafter, 
the application program writes a command with a virtual 
address to the memory management unit. The virtual address 
for this command is translated by the memory management 
unit hardware into a physical address on the input/output bus 
27 and sent directly to the input/output control unit 29 at the 
physical address. The seven highest order bits of the physi- 
cal address designate the address area assigned by the 
operating system to the application program. Since the I/O 
driver #1 is constructed never to map more than one appli- 
cation program to an address area, the seven bits also 
identify the application. 

When an application program writes to the FIFO unit 31, 
the seven upper bits of the address are used to determine the 
sixty-four Kbyte address area which the application has been 
allotted by the operating system. The three bit sub-area 
designation is the physical address on the input/output bus 
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27 used to select one of the eight Kbyte sub-areas which may system addresses to device bus addresses. In the prior art, 

be allotted to a device. The eleven bit offset is used to this selection has always been accomplished by the operat- 

determine the method for (the command or operation to be ing system, 

carried out by) the device, and the thirty-two bit data space Writes to non-zero offset 

is used for the data related to the commanded operation. Ins If the method ofiket is not zero, the puller circuit 40 takes 
a typical write operation, the write to any particular eleven the three bits indicating the sub-area and indexes into the 
bit offset invokes a particular method (a command defining table 36 to the proper register to find the device bus physical 
the operation to be performed) on the object (the input/ address. The puller circuit 40 concatenates that address with 
output asset designated by the present name for the sub- the eleven bit oflfeet designating the method and writes the 
area). However, these eleven bits are also interpreted (1) to lO method and thirty-two bits of data to that physical address on 
create a new data structure representing input/output devices the bus 34. However, if instead of a physical address, the 
which respond to virtual names given by the application value read from the register of the table 36 is a special value 
program, (2) to provide direct translations from virtual which indicates a failed translation, the puller circuit 40 
names to physical addresses of input/output devices on the generates an interrupt which calls the resource manager The 
device bus 34, and (3) to call the resource manager to is resource manager then uses the command at the bottom of 
perform various software operations. the FIFO buffer 31 to perform whatever software operation 
The puller circuit, current address registers, and translation is required by the command. This assures that unsafe opera- 
table tions are always handled by the operating system. 

These operations are accomplished by various circuitry FIG. 6 illustrates in the first two lines one entry in the 

and the resource manager, particularly by a puller circuit 40, 20 translation table 38 utilized in one embodiment of the 

a current physical address table 36 which includes eight present invention. In the specific embodiment described, the 

registers capable of holding address translations for devices translation table 38 may be designed as a hash table in order 

presently in use, and a translation table 38 which may to provide an even distribution of entries in the storage space 

include a much larger number of address translations. The available. The use of a hash table allows the name provided 

puller circuit is illustrated in more detail in FIG. 7. In order 2S by the application program to be used with the area address 

to correctly direct the address and data provided in each as a key to derive an index for storing a translation value. As 

command, the puller circuit 40 reviews the address of the may be seen, the seven bits of the address designating the 

command about to be executed at the bottom of the FIFO area assigned to an application program and the thirty-two 

buffer 31. The puller circuit 40 includes logic which first bit virtual name translate into twenty-three bits seven of 

uses the three sub-area bits of the address to determine 30 which indicate the address of the physical device on the 

which one of the eight current address registers of the device bus and sixteen of which indicate the instance of the 

current physical address table 36 has been seleaed. This data structure which provides the context to be placed on the 

current address register will contain the physical address of input/output device. Additional control bits may also be 

the input/output device on the device bus 34, will receive the included as a part of the translation data stored in the table 

physical address of the input/output device which results 35 38 but are not shown. The hash table form is especially 

from a lookup in the translation table 38, or will indicate a convenient because the lack of a translation typically returns 

software process is to be run be the resource manager a zero which may be used as a special value in the table 36 

Writes to zero offiset in the manner described herein. Alternatively, the table 38 

The puller circuit 40 also includes logic circuit 71 which may be arranged as a lookaside biiffer with the seven bit area 
then determines whether the next eleven method bits of the 40 value and the name used as the index to derive the physical 
address are all zeroes. If the eleven method bits are all address. Each of the last two lines of FIG. 6 indicates one 
zeroes, this indicates a write to the zero offset which is the way in which the bits obtained in the translation are used, 
special calling method used for indicating that the applica- The eleven bits indicating the method invoked are concat- 
tion wants a new translation for an input/output device; and enated with the physical address for the device retrieved 
the puller circuit 40 sends the data to the translation table 38 45 from the translation table 38, and the concatenated value is 
along with the upper seven bits of the address indicating the placed on the bus 34 with data. Each of the input/output 
area and performs a lookup. It will be recalled that when the devices decodes addresses on the bus 34 to determine if it is 
write is to this special calling method, the data is the virtual the addressed device and responds accordingly to the opera- 
name of a device. The result of the lookup is usually an tion indicated by the method, 
address on the device bus 34 and a physical instance number so Creation of a data structure 

defining context which are placed in the register of the table When an application program first writes to the area 

36 pointed to by the three sub -area address bits. When the which it has been allotted by the operating system and 

physical address and instance number are placed in the presuming that no other application is presently utilizing the 

register of the table 36, the puller circuit sends the seven bits FIFO unit 31, the command is ultimately reviewed by the 

indicating the area and the instance number to the input/ 55 associated puller circuit 40. The puller circuit will find that 

output device to change the context on the device. The the application program has selected one of the sub-areas 

input/output device uses the seven bits indicating the area using the three bit sub -area designation, selected an offset 

and the instance number to assure that it has the correct zero using the eleven bits, and has written a predefined name 

context. Thus, by writing to oflfeet zero an application for a particular input/output device in the thirty-two bit data 

program causes an input/output-bus-to-device-bus transla- 60 space. When the application program selects a zero offset as 

tions to be made available for immediate use and the correct the eleven bits representing an operation, the application is 

context to be provided on the device for use with the indicating that it desires to call a data structure which has 

application before an address translation is used, been named and make it immediately available for use. 

Thus, in contrast to all prior ait arrangements which When a zero value is written as the eleven bit offset to any 

furnish address translations, the present arrangement allows 65 one of the sub-areas, this instructs the input/output control 

the application program to select the particular translation unit 29 to make available that one of the sub-areas to the 

which is to be available in the table 36 to translate from newly-named object and to interpret eleven bit offsets within 
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the sub-area as the various methods which are available to resource manager interprets the create command as a create 

an object of that class. method for the predefined object and creates a new instance 

When the register holding the translation for a sub-area of the predefined class of objects, names the instance using 

has been allotted to the particular object, the methods of that the name requested by the application program, and stores it 

object are thereafter invoked by writing to the different 5 as a new data structure in the object database, 

eleven bit offsets available for that particular object. Since Modifying context of newly-created data structure 

there are eleven bits available in a sub- area of 8K bytes, If the application program desires to modify the context 

2048 different methods may be invoked on each object. This values of the input/output device for which it has created a 

provides a sufficient number of different possibilities new object, it writes the name it has selected for the object 

(methods) to suflBce for most devices which an object may lO as data to the zero offset address. The puller circuit 40 causes 

define, a lookup in the translation table 38 using the new virtual 

When the application program writes the name of a data name and the seven bit area identification. Again, there will 
structure as data to offset zero of a sub-area, the puller circuit be no translation for that virtual device name in the trans- 
40 takes the virtual name, adds the seven bits designating the lation table 38 since the data structure which has been 
area, and looks up the concatenated value in the translation 15 created is a software object which has no translation in the 
table 38 to obtain the physical address on the device bus 34 table 38; the special value is placed in the table 36 to indicate 
and the instance of the physical device whidi is responsible a software object; and the operation will be transferred to the 
for the operation represented by the particular object being resource manager. The resource manager reviews the corn- 
named. If a translation is in the table 38, the physical address mand and determines that is a write to a zero offeet. This 
on the bus 34 of the hardware (e.g., line drawing hardware 20 causes the resource manager to look up the new data 
in the graphics rendering engine) should be returned and structure with that virtual name in the object database to find 
placed in one of eight positions (registers) of the current the object which defines the input/output device. The 
physical address table 36 designated by the three bit sub- resource manager uses the seven bits designating the area 
area to which the zero offset was written. However, if the allotted to the application program and the thirty-two data 
translation for the physical object does not exist in the 25 bits providing the virtual name given by the application to 
translation table 38 of the input/output control unit 29, the find objects in its database. 

translation table 38 returns a miss and places a special value When the resource manager finds the data structure, it 
(all zeroes in one embodiment) in place of the physical places the special value in the addressed register of the table 
address in the addressed register of the table 36. The miss 36 instead of an address on the device bus 34 to indicate that 
transfers the operation to the resource manager which uses 30 this is still a software object. Until the physical device is 
the command at the bottom of the FIFO buffer to perform utilized, the application program may send various corn- 
whatever software operation is required by the command. mands as methods on the new object; and these will be 
For example, a miss in the translation table 38 may be used executed by the resource manager A plurality of low num- 
to trap operations which require cxDntext switching before a bered ofiOsets are utilized for modification of a software data 
device is allowed to perform an operation. 35 structure. For example, the application program may send 

Because on a first write to the input/output control unit 29 commands which set the details of the appropriate context 

by an application program, there will be no translation for values for that particular device funaioning with the par- 

the named data structure in the translation table, the opera- ticular application for the particular purpose. This changing 

tion will be transferred to the resource manager. The of context from the context provided by the predefined data 

resource manager in the preferred embodiment of the inven- 40 structure typically occurs before the device is utilized while 

tion has access to the database which includes the data only the software object is affected, 

structures for a number of predefined objects. These objects Placing safe translations in the translation table 

may represent hardware or software which implements Ultimately, when a physical input/output device receives 

various portions of the input/output operations. When an a command which makes a first use of the physical device, 

application program writes the name of a predefined object 45 the resource manager places a translation for the particular 

at an offset zero in one of the eight sub-areas, this is a request virtual-name-to-device-bus-address of the appropriate 

to the resource manager to make the predefined object one physical device in the translation table 38. 

of the eight objects available for immediate use at the It should be noted that the virtual name selected by an 

addressed one of the eight sub-areas. application program for a particular data structure represent- 

The resource manager reviews the details of the command 50 ing an input/output device and its context is used for the later 

being written and determines that is a write to a zero oflEset. retrieval of the address translation for that that input/output 

This causes the resource manager to look at the predefined device. In fact, a number of different application programs 

name to determine the class of the object. When it deter- may use the same virtual name for the same or different 

mines that this is a name for one of the predefined general virtual objects without causing any ambiguity because each 

classes of objects associated with the input/output control 55 object created has its own separate area address bits which 

unit 29, the resource manager looks up the data structure for relate to that application alone. 

that object and makes that object immediately available. To In any case in which a translation for the virtual name to 

make the object immediately available, the resource man- the device bus address for a new physical object is placed in 

ager allots the sub-area to the predefined object but also the translation table 38, a number of additional bits which 

places a special code in the table 36 to indicate that the 60 define the instance of the data structure and therefore indi- 

object is a software object and the resource manager is to be cate any context which is presently a part of the data 

called when the predefined object is addressed, structure and is necessary for the operation of the device 

The application program follows this command calling with the application is also stored in the translation table 38 

the predefined data structure with a command directed to the by the resource manager. Finally, the resource manager 

same sub-area to create an instance of the predefined data 65 restarts the write operation. The lookup in the translation 

structure in the database and name it as the application table 38 then succeeds. This causes the physical address and 

program defines in the data bits of the create command. 7*he instance value (also called context value) to be placed in the 
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register of the table 36 and the puUer 40 to send the seven 
area bits and instance value to the input/output device to 
change the device context. 

When an application program writes the virtual name of 
an object to ofiket zero in one of the sub -areas, and when the 
lookup in table 38 of that virtual name succeeds, the physical 
address of the corresponding device on the device bus 34 
and the instance value are also stored in a slot of the eight 
entry current physical address table 36 which slot corre- 
sponds to the sub-area to which the virtual name was 
written. The table 36 stores the physical address on the 
device bus 34 of the device corresponding to the current 
object accessible in that sub-area, if there is such a device. 
If there is not a physical device or there is no translation in 
the table 38, the entry stores the special value which has no 
translation and therefore causes the input/output control unit 
29 to interrupt into the resource manager. 

It should be noted that the resource manager is involved 
only if a translation for the virtual name cannot be found in 
the translation table 38 and is therefore considered to be 
unsafe. This may happen when the context for the object is 
not in an appropriate device, and the device in question 
cannot perform its own context switching. It may also occur 
if the object in question is of a class that is always imple- 
mented in software because there is no corresponding device 
on the device bus 34. It may also occur if the translation 
table 38 is full and if other resources necessary to implement 
the object are exhausted. 

When the physical address on the device bus 34 and the 
instance value of the device corresponding to the current 
object are first placed in a register of the current address 
table 36, the address is used by the puller circuit 40 to send 
the instance value and the seven bits indicating the appli- 
cation program (and the address area) to the device on the 
device bus 34 (see line three of FIG. 6). The device 
compares the seven bits and the instance value to the area 
and instance it is presently utilizing. If they differ, the device 
changes its context or interrupts the resource manager to 
change its context so that the device is properly initialized 
for the application program. 

Thus, whenever an application program selects a diflferent 
input/output device to utilize a sub-area of the address space 
by writing to offset zero of a register of the table 36, the 
change of input/output device causes the puller to send the 
area bits and the instance value to the input/output device to 
change any required context. 
Writing directly to input/output devices 

With the address translation in a register of the table 36, 
when a next write occurs to that object as indicated by the 
three bits of the address selecting the register for the 
particular sub-area, the offiset address will typically be other 
than zero. TTiis offset will indicate the method invoked on 
the object. This method (indicated by the eleven bits) is 
concatenated with the physical address held in the table 36 
(see line four of FIG. 6) and broadcast on the device bus 34 
to select the particular input/output device and the operation 
indicated by the method which is to be performed by that 
device. All of the devices on the device bvs 34 listen on the 
bus and decode commands addressed to them. 
Current address registers and sub-areas 

Since eight sub-areas are available at once through the 
current address table 36,, an application program may write 
up to eight virtual names for devices the application desires 
to utilize in input/output operations and have physical 
addresses for those devices immediately available by simply 
writing the virtual name to the zero offset of a sub-area. As 
has been explained, this is initially accomplished for each 
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device by writing a predefined object name to the zero offset 
to place that object in a sub- area, creating an instance of that 
predefined object representing an input/output device using 
a virtual name chosen by the application program, writing 

5 the new name as data to the zero offset to place the 
newly-created object in a sub-area, and calling the resource 
manager when it is found that there is no translation for that 
device name in the translation table. The resource manager 
determines that is a write to a zero offset, finds the data 

10 structure for the newly-named object, stores a translation for 
the virtual name to the device bus address of the appropriate 
device in the translation table 38 along with the instance 
value indicating the device context, causes the puller to store 
the context for the named object in the physical device, and 

15 restarts the write operation so that the lookup in the trans- 
lation table 38 succeeds and so that the physical address of 
the corresponding device on the device bus 34 is stored in 
the register of the current physical address table 36 which 
corresponds to the sub -area to which the virtual name was 

20 addressed. Thus, the application program may select each of 
eight objects representing devices for which the translations 
are then immediately available in the registers representing 
the eight sub- are as. 
Thus, up to eight objects (devices) may have address 

25 translations immediately available in the table 36 for the 
application program using the FIFO unit 31. For example, 
one sub-area may have addresses for a line drawing object. 
This object will respond to various of the 2048 possible 
methods available to provide different operations by that 

30 device. One of the methods may designate the beginning 
point of a straight line; another may designate the end of the 
line. By invoking these methods on the line drawing object 
in order, a line may be caused to be drawn on the display by 
a hardware graphics engine. Another of the sub -are as may 

35 hold a color table. Commands to this sub-area may invoke 
a method to fill a portion of a color table of a hardware 
digital-to-analog converter to control the color mode of the 
output display. It should be noted that it is possible for an 
application program to have a number of differently named 

40 data structures and associated contexts for the same actual 
physical input/output device. For example, an application 
program may provide different context values for color 
tables to provide different display results. To make sure that 
the correct context is on a device, whenever an application 

45 program switches to a different register of the table 36, the 
change of sub-area address causes the puller circuit 40 to 
send the address area bits and the instance value to the 
input/output device to change any required context. 
Changing the input/output device in a sub-area 

50 The eight sub-areas available provide a large number of 
output options for an application program. The availability 
of eight sub-areas allows the application to accomplish a 
number of functions without the necessity of a translation 
table lookup and thus speeds input/output operations. 

55 However, since any application program may need to have 
access to aU of the input/output assets which are available, 
the system provides a rapid manner of providing assets in 
addition to the eight devices which are represented by 
objects which fill the eight sub-areas allotted to that appli- 

60 cation program. When all of the eight sub-areas have been 
used by an application program so that input/output-to- 
device bus physical address translations for a device exist in 
each of the eight spaces in the table 36 and the apphcatioo 
program running desires to write to a different input/output 

65 device, the application program may select a new device 
which it desires to use and place its address translation in the 
table 36 in place of any address translation presently occu- 
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pying one of the registers. To accomplish this, the applica- 
tion program writes a new virtual name of a device as data 
directed to the zero oflEsel of any of the eight sub-areas. This 
causes the input/output control unit 29 to replace the object 
presently occupying the sub-area with a new object repre- 
senting the device indicated by the newly presented virtual 
name. This is accomplished by the puller circuit 40 initiating 
a lookup in the translation table 38 and a replacement of the 
device bus address and instance representing context in the 
table 36 designating the object presently in the sub-area with 
the device bus address of the new device if a translation for 
the new object for the physical device has already been 
placed in the translation table 38 by the resource manager. 
Whenever an application program places a different trans- 
lation in a register of the table 36, the change of address 
causes the puller to send the area bits and the instance value 
to the input/output device to change any required context. 

However, if this is the first use of this object by the 
application program, the name-to-physical-address- 
translation is not in the translation table 38. The new virtual 
name causes the virtual-name -to-physical-address transla- 
tion to miss in the translation table 38 so that the operation 
is trapped and sent to the resource manager. Presuming that 
an instance of a predefined data structure has already been 
created under the virtual name, the resource manager rec- 
ognizes the zero offiset as calling for a new object, reviews 
the new name, and finds the data structiu-e for that name in 
the database. It uses the object data structure to obtain the 
instance value indicating the context for that new input/ 
output device and writes the virtual-name -to-physical- 
address translation and instance value into the translation 
table 38. The operation then proceeds and succeeds, the 
physical address and instance value for the object is placed 
in the current physical address table 36 in the register in 
which the object being replaced previously resided, and the 
context of the device is updated. When the next write occurs 
for that named input/output device, the physical address 
translations for that device (object) will be in the current 
physical address table 36 so that it may be immediately 
placed on the bus 34. Thus, the resource manager is called 
and assures that the context on an input/output device is 
correct before its address translation is placed in the physical 
address table 36. 

Whenever any object is named for which the physical 
address is not in the current physical address table 36 but for 
which a translation is available in the translation table 38, 
the lookup of that virtual name succeeds, the physical 
address and the instance value of the corresponding device 
on the device bus 34 is stored in a slot of the current physical 
address table which corresponds to the sub-area to which the 
virtual name was written. Thereafter, writing to an ofifeet to 
this sub -area selects the particular mput/output device and 
the operation (indicated by the method) which is to be 
performed by that device. In this manner, the tables 36 and 
38 act as a two level cache for object name translations 
selected by the application program which the apphcation 
utilizing the FIFO unit 31 may immediately access and 
makes an extraordinarily large number of operations avail- 
able even though the physical address space allotted to the 
program is hmited. 

Although 2048 operations are available for each object 
which is physically on the device bus 34, it is probable that 
some number of the operations (methods) will not be 
implemented in hardware. When an input/output device 
receives a command including a method which it cannot 
carry out, the device addressed responds to the command 
indicated by the offset by saving the saving the method and 



data received and generating an interrupt indicating that the 
hardware cannot deal with the operation. The interrupt calls 
the software of the resource manager so that the resource 
manager may accomplish the operation using the method 
5 and data saved. This allows those operations which are 
invoked very infrequently to be carried out in software, 
while those operations which are used frequently are imple- 
mented in hardware in order to speed up the system. In order 
to assist this operation, each input/output device on the 
10 device bus 34 also provides a signal to the puller circuit 40 
to signal the puller circuit that no commands are to trans- 
ferred to the input/output device which has generated the 
interrupt until the interrupt servicing has been completed. 

Thus, as may be seen, the resource manager is a piece of 
software which is associated with the input/output control 
unit 29 and determines that the input/output control unit 29 
functions correctly. It maintains a database of data structures 
which represent the various input/output devices and the 
context that those devices require to function correctly. It 
fills the translation table 38, initiates the necessary context 
switching for initializing the physical devices, provides 
routines for less used input/output operations which input/ 
output devices may invoke through interrupts, and does 
other things required to run the input/output control unit 29. 
The resource manager may be thought of as part of the 
operating system and takes the place of the device driver 
used in a conventional input/output system. The resource 
manager maps in a part of the physical hardware of the 
input/output control unit 29 called the privileged address 
space. This space is distinct from the FIFO unit. Unlike the 
application programs operating with input/output devices, 
the resource manager both reads and writes this address 
space to perfonm its various tasks. Unlike all of the device 
drivers of the prior art, the resource manager accomplishes 
its functions after the hardware of the input/output control 
unit 29 has been directly addressed by an application pro- 
gram rather than before. Moreover, in the overall operation 
of the input/output control imit 29, the resource manager is 
used infrequently compared to the hardware portions of the 
input/output control unit 29 since the resource manager 
attends only to creation operations, the various software 
implementations of methods, and unsafe operations. 

The new architecture provides an extraordinary amount of 
flexibility for an application program. In the embodiment 
illustrated, the FIFO unit 31 is dedicated to the use of a 
single application at any time. Since an address area is 
mapped to the address space of only one application 
program, all of the commands in the FIFO unit 31 are 
directed to responding to that program. Moreover, once an 
object has been made accessible in a sub-area, the three bits 
designating that sub-area indicate the meaning of the eleven 
bits designating the operations which apply to the object in 
that sub-area. The name of each object has thirty-two bits 
(the thirty-two data bits written to oflEset zero) of argument 
Thus, if each of the methods or commands available to each 
of the objects is considered to function in the manner of a 
register, there are four billion objects which may be 
addressed and there are 2048 registers available to each 
object. This provides thirty-two terabytes of methods for 
input/output devices available to each application program. 
Transferring the FIFO unit between application programs 
The input/output control unit 29 also functions to rapidly 
switch between application programs. When in the illus- 
trated embodiment the input/output control unit 29 is 
responding to commands from one application program and 
receives a command from a second application program, the 
FIFO unit 31 changes and links itself to the second program. 
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If the FIFO unit is empty, this may occur immediately. If the The pusher then interrupts the resource manager which waits 

FIFO unit is filled with commands from the first application for the puller circuit 40 to complete processing the com- 

program, these commands will be executed before the mands remaining in the FIFO buffer. When the puller circuit 

commands of the new application program are handled. In 40 has completed emptying the FIFO unit 31, the resource 

some cases, this may require that the commands from the 5 manager takes over the operation of processing the com- 

second program be written into local memory associated mands in runout memory, 

with the input/output control unit 29 so that their execution The resource manager takes over each of the functions of 

will be delayed until the commands from the first application the puller 53 in so far as the transferring of commands to the 

program have cleared the FIFO unit. In this way, the FIFO various portions of the input/output control unit 29 are 

unit 31 appears to furnish an individual FIFO unit for each lO concerned until any runout memory storing commands 

of up to 128 incoming programs in this particular embodi- originally directed to that FIFO unit 31 has been emptied, 

ment. The resource manager must execute the commands in 

In order to assure that the commands from different sequence in order for the operations to be executed correctly, 

programs may utilize a single FIFO unit 31 in the manner of For this reason, a runout register 78 and comparator 75 are 

a cache, the input/output control unit 29 utilizes the pusher 15 provided so that all commands addressed to the overfiowing 

circuit 53. The pusher circuit 53 includes a comparator 73 FIFO unit 31 after a first command is sent to the runout area 

which compares the seven bits of each new command are also sent lo the runout area. The value in the register 45 

indicating the address area with the seven bits held in the is held at zero until all of the data in both the FIFO unit 31 

register 42 indicating the application program presently and the runout area have been cleared, 

using the FIFO unit 31. If these bits differ from those in the 20 The first command from the new application program 

register 42 and there are commands in the FIFO unit 31, the attempting to write to an input/output device must be an 

pusher circuit 53 issues a hold command on the bus 27 to offset zero write with the virtual name of a device to make 

stop additional commands being sent from the new appli- an input/output object which has been created accessible in 

cation program. During the holdoff period, the FIFO unit 31 one of the sub-areas or to create an object if it does not yet 

may clear all of the commands of the old application 25 exist. When the command ultimately arrives at the bottom of 

program. If the puller circuit 40 has completed emptying the the FIFO unit 31, the virtual name of the device that 

FIFO unit 31 so the FIFO unit 31 is clear of commands when corresponds to the object is concatenated with the seven 

a command from a new application arrives, the new appli- highest bits in the register 52 indicating the application area 

cation is detected; and each of the registers of the table 36 and looked up in the translation table 38 to determine the 

is set to the special value zero so that a new device address 30 physical address on the device bus 34 for that object. If the 

and new instance value must be placed in a register and translation exists in the translation table 38, the physical 

context placed on any input/output device before a com- address on the bus 34 is placed in the current physical 

mand can be transfened to it. address table 36 and the context on the device is changed. 

However, when the bus holdoff expires, commands from The physical address on the bus may then be concatenated 

the old program may still be in the FIFO unit 31; and the new 35 with the eleven bits of the method designated in later 

commands may have to be placed in local memory on the commands which will cause immediate transfer of the 

input/output control unit 29. In one embodiment, the local command on the bus 34 to the device. If no translation exists 

memory used for this purpose is an off-screen portion of the in the translation table 38 but an object has already been 

memory in the frame buffer utilized by the graphics con- created, the input/output control unit 29 generates an inter- 

troller 33. 40 rupt to the resource manager. (If the object has not yet been 

In one embodiment of the invention, a register 45 is created, the creation takes place in the manner described at 

included as a part of the input/output control unit 29. The length above.) For an existing object, the resource manager 

register 45 stores an indication of the number of available receives the interrupt and recognizes that this is a call for a 

entries in the FIFO unit 31. The use of this register 45 allows new input/output resource to be made accessible in that 

a requirement to be placed on an application program 45 sub-area. It places the translation for a physical device in the 

attempting an access of the input/output control unit 29 that translation table and changes any context which need to be 

it first determine whether space is available in the FIFO unit changed to service the new application. Then it returns the 

31. It also allows an application presently using the operation to the input/output control unit 29. The input/ 

resources of the input/output control unit 29 to proceed output control unit 29 executes the command by placing the 

without overflowing the FIFO unit 31. The application 50 physical address in the physical address table, 

program may obtain a boundary value indicating the number A similar process takes place when the reference to the 

of free entries in the FIFO unit by reading from a designated translation table results in an indication that there is no 

offset in any of the sub-areas of its mapped area. The translation in the translation table for the name, perhaps 

applicationmay write up to the amount of data designated by because the input/output object is a software object. An 

this boundary value without further testing and be certain 55 intermpt is generated which transfers the operation to the 

that overflow of the FIFO unit will not occur. It should be resource manager. The resource manager reads the name 

noted that this read operation is the only read necessary in from the input/output control unit and performs the lookup, 

dealing with the input/output control unit 29. It discovers that the named object is to be implemented by 

If the pusher circuit 53 has generated a holdoff command software and places an indication in the table 36 that the 

to the bus 27 in order to stop the flow of write commands 60 resource manager is to be called. If there is no translation for 

when a new program attempts to utilize the FIFO unit 31 and the object because the corresponding physical device does 

after the holdoff period has expired the FIFO buffer is still not exist as a part of the input/output control unit, it must be 

full as determined by logic 72, the pusher 53 sets the value executed by the resource manager. In the case of a hardware 

in the register 45 to zero and transfers each of the next input/output device which does not perform a little used 

commands received on the bus 27 to mnout memory asso- 65 operation in hardware, the hardware translation is actually 

ciated with the input/output control imit 29, recording the placed in the translation table 38 and the current physical 

area bits, address, and data of each command as it is stored. address register 36. The command is transferred to the 
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input/output device which discovers thai the command is to 
non-existent hardware, and interrupts the resource manager. 
The resource manager emulates the requested operation, 
possibly using devices other than those on the device bus 34. 

Although the present invention has been described in 5 
terms of a preferred embodiment, it will be appreciated that 
various modifications and alterations might be made by 
those skilled in the art without departing from the spirit and 
scope of the invention. The invention should therefore be 
measured in terms of the claims which follow. 

What is claimed is: 

1. A computer system comprising: 
a central processing unit, 

a system input/output bus, 

and hardware input/output address translation apparatus 
accessed at a physical input/output address for trans- 
lating addresses and data in commands furnished by an 
application program to physical input/output device 
addresses and furnishing context for an input/output 
device to function with an application program. 

2. A computer system as claimed in claim 1 in which the 
hardware input/output address translation apparatus com- 
prises: 

a storage circuit for holding a physical address of an 
input/output device which is a translation of an address 
and data furnished by an application program, and 

a translation table storing physical addresses which are 
translations of addresses and data furnished by appli- 
cation programs together with context values for con- 
trolling the context to be placed on an input/output 
device for which an address translation is to be pro- 
vided. 

3. A computer system as claimed in claim 2 in which the 
hardware input/output address translation apparatus further 
comprises: 

a loading circuit to place a selected physical address of an 
input/output device from the translation table in the 
storage circuit and context on the input/output device 
addressed. 

4. A computer system as claimed in claim 2 in which the 
hardware input/output address translation apparatus further 
comprises: 

a loading circuit to place a selected physical address of an 
input/output device from the translation table and a 
value signifying context on the input/output device 45 
addressed in the storage circuit. 

5. A computer system as claimed in claim 3 which further 
comprises: 

a database of data structures each including a physical 
address of an input/output device and context to be 50 
placed on the input/output device to function with a 
particular application program. 

6. Hardware input/output address translation apparatus 
accessed at a physical input/output address for translating 
addresses and data in commands furnished by an apphcation 55 
program to physical input/output device addresses and fur- 
nishing context for an input/output device to function with 

an application program comprising: 

a storage circuit for holding a physical address of an 
input/output device which is a translation of an address 60 
and data furnished by an application program, and 

a translation table storing physical addresses which are 
translations of addresses and data furnished by appli- 
cation programs together with context values for con- 
trolling the context to be placed on an input/output 65 
device for which an address translation is to be pro- 
vided. 



7. Hardware input/output address translation apparatus as 
claimed in claim 6 in which the hardware input/output 
address translation apparatus further comprises: 

a loading circuit for placing a selected physical address of 
an input/output device from the translation table in the 
storage circuit and context on the input/output device 
addressed. 

8. Hardware input/output address translation apparatus as 
claimed in claim 6 in which the hardware input/output 
address translation apparatus further comprises; 

a loading circuit to place a selected physical address of an 
input/output device from the translation table and a 
value signifying context on the input/output device 
addressed in the storage circuit. 

9. Hardware input/output address translation apparatus as 
claimed in claim 7 which further comprises: 

a database of data structures each including a physical 
address of an input/output device and context to be 
placed on the input/output device to frinction with a 
particular application program. 

10. A computer system comprising: 
a central processing unit, 

a system input/output bus, 
an input/output device, and 

an input/output control unit having a system physical 
address joined to the system input/output bus for trans- 
lating addresses and data on the system input/output 
bus to physical input/output device addresses and plac- 
ing context on addressed input/output devices. 

11. A computer as claimed in claim 10 in which the 
input/output control unit includes: 

a register having a system input/output address and stor- 
ing a physical address of an input/output device and a 
context value for an application program to function 
with the input/output device, and 

accessing circuitry responsive to a command from an 
application program directed to the system input/output 
address of the storage circuit to provide the context 
value to the input/output device at the physical input/ 
output address stored in the register. 

12. A computer as claimed in claim 11 further comprising: 
a memory circuit storing physical addresses of input/ 

output devices and context values for the input/output 
devices to function with application programs, and 
a loading circuit responsive to commands from an appli- 
cation program to place a selected physical address of 
an input/output device from the memory circuit in the 
storage circuit and cause the accessing circuit to furnish 
the context value to the input/output device, 

13. A computer as claimed in claim 12 which further 
comprises: 

a database of data structures each including physical 
addresses of input/output devices and context to be 
placed on the input/output devices to function with a 
particular application program. 

14. A computer as claimed in claim 10 fiirther comprising: 
a plurality of registers each having a system input/output 

address and holding a current physical address of an 
input/output device and a context value for an appli- 
cation program to function with the input/output 
device, and 

in which the accessing circuit is responsive to commands 
from an application program to system addresses of the 
registers to provide context values to input/output 
devices at the physical input/output addresses stored in 
the registers. 
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15. A method for translating addresses and changing 
context on input/output devices comprising the steps of: 

placing a physical address and context value for an 
input/output device in a translation circuit having a 
physical input/output address when an input/output 
device is first utilized with an application program, and 
placing context on the input/output device using the 
context value in the translation circuit before an address 
translation is furnished for a command directed to the 
input/output device. 

16. A method as claimed in claim 15 in which the step of 
placing a physical address and context value for an input/ 
output device in a translation circuit having a physical 
input/output address when an input/output device is first 
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utilized with an application program comprises deriving 
physical address aod context value for an input/output 
device from a data structure. 

17. A method as claimed in claim 15 further comprising 
the initial steps of: 
creating a database of data structures in which each data 
structure represents includes a physical address and 
context for an input/output device, 
copying a data structure and associating the data structure 

with an application program, and 
changing the context in a copied data structure to provide 
context for use with the application program. 
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